I think this is in good shape now. @simonge, do you agree?

The issues with the functionality of the code have not been addressed yet. It might not be a problem for the majority of datasets being processed at the moment but will be a significant bug and may cause unnecessary confusion down the line for any processing of events distributed throughout time.

The issues with the functionality of the code have not been addressed yet. It might not be a problem for the majority of datasets being processed at the moment but will be a significant bug and may cause unnecessary confusion down the line for any processing of events distributed throughout time.

I believe the main conflicts lies in the meaning of tMin. The way I intended tMin and tMax to work is that pulse generation happens at time tMin < t < tMax with no signal outside of this range. The generated pulse will be passed on to the digitization class which convert the pulse to TDC and ADC value.

You proposed that tMin = _DigitizeTime(time) where time = hit.getTime() * dd4hep::ns;, but I fail to understand why that should be the case. If tMin is indeed hit.getTime(), that means the pulse always begin at time (internal EICROC time, not global time) = 0! I don't think that should be the case. If a hit arrives at t (global time) = 5 ns (let's say), then the way I envision my class to work is that for the first 5 ns, the pulse will be flat (i.e. no voltage), and then the voltage increases and decreases according to the landau template pulse.

I understand that collision time will not be zero both due to synchronization issue between the global 100 MHz clock and the local EICROC 40 MHz clock and finite size of bunches, if that's what you want me to implement, I can do it by shifting the tMin of each event by a random number. However, the last time I communicate this idea to you, it seems like that's not what you are asking either.

Another point you raise that I cannot agree is that we cannot discard hit that arrives at t > 25 ns. To the best of my knowledge, that's really how LGAD works in reality where signal that arrives outside beyond the 40 MHz cycle is simply discarded. As a matter of fact, the pulse timing are defined by the 40 MHz clock. It's why I don't believe tMin can be related to the hit time. tMin is when a new cycle of 40 MHz clock starts regardless of when a hit arrives.

You also mentioned that I need to deal with start time alignment. That's only an issue if tMin is not a constant in an event. If tMin = 0, there is no need to worry about mismatch of bin edges because every TDC is binned with respect to the 40 MHz clock regardless of when a hit arrives. That's another reason why I don't think tMin = _DigitizeTime(time) is right.

To be fair, none of the people that I talked to at BNL can firmly confirm or correct my understanding. Since the electronics are still in the design phase, anything can change. What I've said (and programmed in this pull request) is my best guess at what should happen. I program my PulseGenerator this way because I believe it reflects how the detector works in reality.

I believe we disagree on how EICROC work, and not mistakes on programming. If we can't reach an agreement on how time works, then unfortunately there is no way I can continue the development of this digitization code. Will you be interested in a Skype/Zoom meeting sometime next week so we can resolve our misunderstanding?

Hi @ssedd1123 and @simonge, I suggest we discuss this digitization issue in the simulation WG meeting on Dec. 17 (Tuesday) at 10 am EST. Would the time work for you? https://indico.bnl.gov/event/23277/

Hi @ssedd1123 and @simonge, I suggest we discuss this digitization issue in the simulation WG meeting on Dec. 17 (Tuesday) at 10 am EST. Would the time work for you? https://indico.bnl.gov/event/23277/

That works for me. I will prepare a presentation.

Hi @ssedd1123 and @simonge, I suggest we discuss this digitization issue in the simulation WG meeting on Dec. 17 (Tuesday) at 10 am EST. Would the time work for you? https://indico.bnl.gov/event/23277/

That works for me. I will prepare a presentation.

I'm happy to discuss at the meeting too, hopefully discussing in person and providing some time diagrams will clear things up. I realise you suggested this earlier too.

Thanks! The dedicated discussion has been scheduled on Dec. 17 (Tuesday) at 10 am EST: https://indico.bnl.gov/event/23277/